Feat/get configuration action - #609
Conversation
Add a get-configuration Juju action so operators can inspect the effective haproxy configuration for debugging without shell access to the unit. - source=disk (default): return the applied /etc/haproxy/haproxy.cfg - source=relations: preview the configuration the next reconcile would generate from the current haproxy-route relation data (read-only; no file writes or service reload) - Log a warning when the effective configuration matches the default (no proxy backends configured) and, in relations mode, when a haproxy-route-policy relation makes the policy backend converge asynchronously (source=disk stays authoritative) - Extract shared template-context and render-to-string helpers so the reconcile and preview paths cannot drift AI-assisted.
Thanhphan1147
left a comment
There was a problem hiding this comment.
second pass, some more comments, I think we're getting there!
Co-authored-by: Phan Trung Thanh <trung.thanh.phan@canonical.com>
…rsing in _configuration_is_default fails
…on that test both actions. While not the best use of parallelism, it is organized better as all action testing is under one file.
Thanhphan1147
left a comment
There was a problem hiding this comment.
Looks good, I think there's only the refactoring and grouping of the tests left until we're good to merge
Co-authored-by: Phan Trung Thanh <trung.thanh.phan@canonical.com>
Hey @Thanhphan1147, I believe I have already refactored to test_action that combines both Juju action testing and I used parametrize to group the two existing default-config-warning tests into test_default_configuration_warning. I'm not sure what your comment is point towards. Are you perhaps referring to combining the TestsGetProxiedEndpointsAction with my TestGetConfigurationAction class and refactor to be one class that tests all action? |
|
@minulo if you look at the unit tests in this repo we don't put them under a test class, since the module should provide sufficient logical grouping already. Can you remove the test class and just keep the tests as isolated methods? |
@Thanhphan1147 I see... I will then turn it to individual functions then. I assumed using a class would have been the correct choice given the tests for the other action, TestGetProxiedEndpointsAction, were constructed as a class when the other unit tests were all functional. I assume that there are some reason for this that I am not aware of. |
|
@minulo oh I think the other tests in that file just happen to not follow the convention of the repo for some reason 😄 We'll have to fix that too. |
Thanhphan1147
left a comment
There was a problem hiding this comment.
Good to merge once the tests are refactored
Cool, I can handle it in different PR, probably next sprint if you want. |
What this PR does
Add a get-configuration Juju action so operators can inspect the effective haproxy configuration for debugging without shell access to the unit.
Why we need it
The haproxy charm creates configuration based on its haproxy-route, haproxy-route-policy, and haproxy-route-tcp relations, but there is no way to inspect the effective configuration without shell access to the unit. This spec proposes a get-configuration Juju Action that returns the charm’s configuration out to stdout by both reading from disk and calculating the potential resulting configuration based on current relations.
Checklist
docs/changelog.mdwith user-relevant changesdocs/release-notes/artifacts. If no change artifact is necessary, I tagged the PR with the labelno-release-note.